Teresa, we were not very clear in the instructions, so I need to apologize. The origin_date needs to be on a Sunday, as the first date when data are not used for that weeks forecasts (i.e., this week, the origin_date would be 2/25/2024). Are you able to modify that and your file name to reflect this change?

Also, there seems to be a problem with a ":" in your metadata.

Thanks! Shaun

@shauntruelove No worries, I changed the date. Also added a space after a ":", hopefully that solves the metadata issue?

You're probably aware but just in case you're not, the guidelines in the word doc says the origin date is the Saturday following the submission Due Date, in case you want to update that.

@tkcy As for metadata, could you chenge the license line as:

license: "CC-BY-4.0"

sorry for the inconvenience, but this should resolve the error on model-metadata

@tkcy Could you double check the content of .parquet in view of column 'type'?

And on the 2nd message, I think it was about 'horizon'. In the hub configuration we need [1-4] as required, but owing to the type error beforehand this message might be shown. Please check the content out firsst.

Notice: ! 2024-02-25-CU-RSV_SVIRS.parquet: Column data types do not match hub schema.
origin_date should be "Date " not "character ", horizon should be
"integer " not "double ", output_type_id should be "double " not
"character "
✖ 2024-02-25-CU-RSV_SVIRS.parquet: EXEC ERROR: Error in purrr::map(x,
~pad_missing_cols(.x, all_cols)) : ℹ In index: 4. Caused by error in
value[[jvseq[[jjj]]]]: ! subscript out of bounds

We are now investigating on the above, please give us time(we apologize for the inconvenience)

Thank you

Koji

@kjsato trying again

@tkcy thanks! and sorry for the inconvenience. I updated tasks.json in main, could you merge or replace it in your tkcy:main?

Then I think the submission will pass if you can resolve the mismatches that appeared in the Notice line above.

Hrm so we had this problem with the origin datetime format for our RSV scenario hub submission - my computer somehow adds time zone info that is not visible on my end. it was solved there by converting to character format. Maybe I'll try going back to character.

Hrm so we had this problem with the origin datetime format for our RSV scenario hub submission - my computer somehow adds time zone info that is not visible on my end. it was solved there by converting to character format. Maybe I'll try going back to character.

Coud you use below for example before saving the data without changing the type "Date"?
data1$origin_date <- as.Date(data1$origin_date)

We use Matlab, not R, so there are differences in translation.

Okay, if other errors are resolved, I will transform the column as simple ones then issue an new pr with this reference on my side

I'm trying again here, with the date modified. It also looks like one of the error messages says point forecasts are invalid.
Should I remove those?

Yes, once if possible.
And note that the required output_type_ids for outpout_type 'quantile' are:

[
                                0.01,
                                0.025,
                                0.05,
                                0.1,
                                0.15,
                                0.2,
                                0.25,
                                0.3,
                                0.35,
                                0.4,
                                0.45,
                                0.5,
                                0.55,
                                0.6,
                                0.65,
                                0.7,
                                0.75,
                                0.8,
                                0.85,
                                0.9,
                                0.95,
                                0.975,
                                0.99
                            ],

so please pay attention that the others will be handled as invalid.

The attached parquet is the revision which I made converted the origin_date column. Just FYI(gzipped to attach here 2024-02-25-CU-RSV_SVIRS.parquet.gz). By using it, only one remaining issue is:

✖ 2024-02-25-CU-RSV_SVIRS.parquet: `tbl` contains invalid values/value combinations.  Column `output_type_id` contains
  invalid values "0.15000000000000002", "0.35000000000000003", "0.49999999999999994", "0.5499999999999999",
  "0.5999999999999999", "0.6499999999999999", "0.7999999999999999", and "0.8999999999999999".

Please take a look at the contents and see if there is a possibility of correction

Hi @tkcy
It is true that we need to consider other countermeasures during validation, but it seems that there will be no particular problem with rounding the output_type_id this time, so how about that? I would appreciate it if you could take a look at the attached data which output_type_id fields were converted by using round(df$output_type_id, 3)

2024-02-25-CU-RSV_SVIRS.parquet.gz

Thanks, that looks good.

okay, I will proceed with it